home *** CD-ROM | disk | FTP | other *** search
/ CU Amiga Super CD-ROM 17 / CU Amiga Magazine's Super CD-ROM 17 (1997)(EMAP Images)(GB)[!][issue 1997-12].iso / CUCD / Programming / DiceSource / src / dlink / link.txt < prev    next >
Encoding:
Text File  |  1992-10-25  |  8.4 KB  |  247 lines
  1.  
  2. dlink c.a prg1.o prg2.o c.lib amiga.lib auto.lib x.o
  3.  
  4. C.O:
  5.     text,code
  6.     ai0,code
  7.     ai1,code
  8.     ae0,code
  9.     ae1,code
  10.     ac,code
  11.     libdata,data
  12.     libbss,bss
  13.  
  14. (oops, just realized that my declarations in libbss,bss should really
  15. be in libdata,data to guarentee the c.o works with large-data model
  16. applications that declare more than 64K of initialized data!)
  17.  
  18. PRG1.O:
  19.     text,code
  20.     ai0,code
  21.     data,data
  22.     bss,bss
  23.  
  24. PRG2.O:
  25.     text,code
  26.     data,data
  27.     bss,bss
  28.  
  29. C.LIB:
  30.     text,code
  31.     ai0,code
  32.     libdata,data
  33.     libbss,bss
  34.  
  35.     ...
  36.  
  37. AUTO.LIB:
  38.     text,code
  39.     ai0,code        (library openning)
  40.     ae0,code        (library closing)
  41.  
  42. X.O:
  43.     ai0,code        (RTS)
  44.     ai1,code        (RTS)
  45.     ae0,code        (RTS)
  46.     ae1,code        (RTS)
  47.     ac,code        (RTS)
  48.  
  49. ------------------------------------------------------------------------
  50.                 LINK STEP 1
  51.               LIKE-NAMED SECTIONS
  52.  
  53.     C:text PRG1:text PRG2:text C.LIB:text AMIGA.LIB:text AUTO.LIB:text
  54.  
  55.     C:ai0  PRG1:ai0 C.LIB:ai0 AUTO.LIB:ai0 X.O:ai0 (rts)
  56.  
  57.     C:ai1  X.O:ai1 (rts)
  58.  
  59.     C:ae0  AUTO.LIB:ae0 X.O:ae0 (rts)
  60.  
  61.     C:ae1  X.O:ae1 (rts)
  62.  
  63.     C:ac   X.O:ac  (rts)
  64.  
  65.     C:libdata    C.LIB:libdata
  66.  
  67.     C:libbss    C.LIB:libbss
  68.  
  69.     PRG1:data  PRG2:data
  70.  
  71.     PRG1:bss   PRG2:bss
  72.  
  73. ------------------------------------------------------------------------
  74.                 LINK STEP 2
  75.                GROUP BY TYPE
  76.          (ORDER COMBINED SECTIONS ACCORDING TO FIRST-ENCOUNTERED)
  77.  
  78.  
  79.     C:text PRG1:text PRG2:text C.LIB:text AMIGA.LIB:text AUTO.LIB:text +
  80.     C:ai0  PRG1:ai0 C.LIB:ai0 AUTO.LIB:ai0 X.O:ai0 (rts) +
  81.     C:ai1  X.O:ai1 (rts) +
  82.     C:ae0  AUTO.LIB:ae0 X.O:ae0 (rts) +
  83.     C:ae1  X.O:ae1 (rts) +
  84.     C:ac   X.O:ac  (rts) +
  85.  
  86.     C:libdata    C.LIB:libdata +
  87.     PRG1:data  PRG2:data
  88.  
  89.  
  90.     C:libbss    C.LIB:libbss +
  91.     PRG1:bss   PRG2:bss
  92.  
  93. ------------------------------------------------------------------------
  94.                 LINK STEP 3
  95.                GROUP ACCORDING TO MODEL
  96.         ( SMALL DATA, SMALL CODE MODEL LETS SAY)
  97.  
  98.     [ALL CODE GROUPS]                -> CODE HUNK
  99.  
  100.     [[ALL DATA GROUPS] [ALL BSS GROUPS] ]   -> DATA HUNK
  101.     [---------- small data section -----]
  102.  
  103. ------------------------------------------------------------------------
  104.     (another example of another possible final-merge.  Dice has an
  105.     option to do put everything into a single hunk, i.e. put the
  106.     read-only initialized data section into the code hunk for a
  107.     residentable program)
  108.  
  109.                 LINK STEP 3
  110.                GROUP ACCORDING TO MODEL
  111.     (SMALL DATA, SMALL CODE, RESIDENTABLE, SINGLE-HUNK EXAMPLE)
  112.  
  113.     [ALL CODE GROUPS] [ALL DATA GROUPS]     -> CODE HUNK
  114.                (read only copy)
  115.              ^
  116.              Nominal linker-defined symbols created to point
  117.              here, give the size of the data and bss , etc...
  118.  
  119.  
  120. Basically, all DLink needs to do is guarentee that like-named sections
  121. are merged first, then unlike-named sections (i.e. small-data and small-code
  122. model), and that the final merged sections are ordered the same as they
  123. occur in the link list.  For example:
  124.  
  125. dlink c.o prg1.o prg2.o c.lib amiga.lib auto.lib x.o
  126.  
  127. oh yah, also that original section ordering within the assembly file is
  128. preserved.  So, for example, my c.o (enclosed) declares the following
  129. sections:
  130.     text,code
  131.     autoinit0,code
  132.     autoinit1,code
  133.     autoexit0,code
  134.     autoexit1,code
  135.     autoconfig,code (new, experimental)
  136.     libdata,data
  137.     libbss,bss
  138.  
  139. Then, say, that prg1.o declares:
  140.     text,code
  141.     autoinit0,code
  142.     data,data
  143.     bss,bss
  144.  
  145. And, x.o declares (x.o is also enclosed):
  146.     autoinit0,code
  147.     autoinit1,code
  148.     autoexit0,code
  149.     autoexit1,code
  150.     autoconfig,code
  151.  
  152. Now, section ordering in the final merge will use the section ordering
  153. determined by the object modules as they are scanned.  Thus, when c.o
  154. declares libdata,data and libbss,bss BEFORE any other module can declare
  155. data,data and bss,bss, that means that in any final DATA section merge,
  156. libdata will always occur BEFORE data,data , and libbss will always come
  157. before bss,bss ...  This guarentees that if my c.lib contains only
  158. initialized data declarations they will ALWAYS be in range of the small-data
  159. model even if the user declares >64K of initialized data (data,data).
  160.  
  161. This may be confusing.    c.o declares libdata,data and libbss,bss, and
  162. a program module declares data,data and bss,bss .  The final result is
  163. actually libdata+data+libbss+bss because the merge is a two step
  164. process -- first all inZtialized data sections and then all bss sections,
  165. finally merge the two groups together to get the final result.    (also,
  166. obviously libdata+data must come before libbss+bss to take advantage of
  167. the use-bigger-length-in-header trick for non-residentable programs so
  168. dlink forces that).
  169.  
  170. In anycase, since c.o declares text,code before autoinit0,code and other
  171. code hunks, this forces the text,code section to occur first when the
  172. code sections are merged together at the end.  Here is an example of
  173. the final merged state of the code sections:
  174.  
  175.     c.o-text prg1.o-text prg2.o-text c.lib-text amiga.lib-text auto.lib-text
  176.     x.o-text (if x.o had a text section, it would go last).
  177.  
  178. The autoinit0, autoinit1, and other sections are merged in the same
  179. way.  The next level group merge would result in the final code hunk:
  180.  
  181.     [ALL TEXT SECTIONS][ALL AUTOINIT0 SECTIONS]....[ALL AUTOCONFIG SECTIONS]
  182.  
  183. The ordering of the section groups in the final link is determined by the
  184. order they are encountered in the link.  Thus c.o's autoinit0 section is
  185. guarenteed to come FIRST in the [ALL AUTOINIT0 SECTIONS
  186. group, and x.o's autoinit0 section (containing the RTS), is guarenteed
  187. to come LAST in the [ALL AUTOINIT0 SECTIONS
  188. group (oops, forgot the ']').
  189.  
  190. Section ordering within a given library is not guarenteed since the
  191. library modules may be 'included' in the link in different orders
  192. depending on how many times dlink must scan the library.  However,
  193. section ordering BETWEEN libraries is guarenteed.  Thus, all sections
  194. in C.LIB come first in their respective groups.  All sections in
  195. AMIGA.LIB come next in their respective groups, and all sections in
  196. AUTO.LIB come after the other library sections but come BEFORE x.o's
  197. sections -- in their respective like-named groups)
  198.  
  199. So, with this formal definition of how sections are combined together,
  200. first like-named sections, then grouped according to initial occurance
  201. (if c.o declares text and then autoinit0, and some later module
  202. declares autoinit0 and then text, the group ordering is still text first
  203. andautoinit0 second), then finally combined according to class (CODE,
  204. DATA, and BSS), One can declare an arbitrary number of autoinit style
  205. sections where the startup code can obtain a pointer to the section
  206. simply by declaring the section and defining a symbol, and reference
  207. the end of the section by simply included a post-object module after
  208. all object modules and libraries in the link which declares said
  209. sections and another symbol).  It also allows an autoinit style section
  210. to be terminated with a single RTS (i.e. x.o contains the RTS), so
  211. any intermediate object modules and libraries can simply 'lay down code'
  212. in that section and it all gets combined and run sequentially at the
  213. end.
  214.  
  215. module inclusion follows normal library rules for libraries... I did not
  216. need to implement any kind of loose binding in dlink.  The reason for this
  217. is obvious.  Take, for example, auto.lib ... auto.lib is how I indirectly
  218. open libraries whos base variables are referenced but not declares.  A
  219. module in auto.lib declares the base variable.    If the base variable has
  220. been referenced but not declared
  221. then normal library rules cause the auto.lib module to be included.  But
  222. since autoinit sections are also part of the module, they get
  223. automatically get included and grouped with other autoinit sections.  So,
  224. one gets direct action out of an indirect reference... a sort of loose
  225. binding implemented a different way.  Even more loose than what you were
  226. planning I think!
  227.  
  228.                                   -Matt
  229.  
  230. -------- Original Message --------
  231.  
  232. From: jtoebes@BYTECOSY
  233. Date: Mon, 10 Dec 90 18:51:11 EST
  234. To: mdillon@BYTECOSY,
  235.  skrueger@BYTECOSY
  236. Message-Id: <memo.5954@BYTECOSY>
  237. Subject: Blink extensions...
  238.  
  239. I have been thinking about the stuff you are doing and there are some
  240. interesting ideas with the merging of initialization that I am starting
  241. to like (with some minor caveats).  The issue the still continues to
  242. bother me is the requirement for using c.o/x.o.  I would like to get a
  243. copy of your specifications for the extensions so that we can see
  244. what we need to do to make it part of the official Blink standard (unless
  245. you have some objection to that).
  246.  
  247.